The present invention relates to computer networks, and more particularly, to the management of components in computer networks.
Information Technology (IT) systems, methods and computer program products, including, for example, computer networks, have grown increasingly complex with the use of distributed client/server applications, heterogeneous platforms and/or multiple protocols all on a single physical backbone. This increase in the complexity of systems may make solution management more complex. Solutions may include collections of software and hardware components to address specific customer business requirements. In a solution, problem determination (PD) may include problem detection, isolation, and resolution using messages/events generated by components participating in a solution across multiplicity of platforms.
In conventional systems, components, such as applications, middleware, hardware devices and the like, generate data that represents the status of the component. This component status data will, typically, be consumed by some management function utilized to monitor the system and/or for problem analysis/resolution. The management function may, for example, be a user reading a log file or a management application that is consuming the data for analysis and/or display. In conventional systems, components and component owners are responsible for determining what data is provided, in terms of format, content, and/or completeness, typically resulting in differing component status formats.
One difficulty that may arise from the use of differing component status formats is in the analysis of problems for differing components or from different versions of a component. Knowledge bases have conventionally been used to map component status data, such as error log messages, that are reported by components to symptoms and eventually to fixes for problems. For example, there are symptom databases utilized by International Business Machines Corporation, Armonk, N.Y., that map WebSphere error log messages to symptoms and fixes. These databases typically work on the assumption that if you see a specified error message (e.g., message “123”) from a specified component (e.g., component “XYZ”), then a particular symptom is occurring (e.g., the performance is slow) and a predefined remedy (e.g., increase the parameter “buffsize” to 10) will likely fix the problem.
However, the use of differing component status formats in the analysis of problems for differing components or from different versions of a component may make it difficult to write correlation rules to obtain status information about the system from data provided by two different components. In other words, message/event logs generated by components may be invariably product-centric, and may adhere to standards and terminology that are unique to a particular vendor (or even a particular application). For example, if a first vendor of a monitoring tool includes a certain status information field when reporting the amount of occupied memory of a device, and a second vendor does not include the same field or includes the field but calls it something different or formats it differently, the information provided by the devices may be difficult to use. In order to reduce the cost of problem analysis and increase the speed and accuracy of problem resolution, it may be helpful for diagnostic data from all components in the solution to be accessible in a consistent manner. As such, the formats of the fields in each message may need to be converted to a common format before the information in the fields may be used efficiently.
In automatic computing system management, also known as autonomic computing, an adapter may be used to convert messages from various components into a common format. For example, IBM's Generic Log Adapter (GLA) may be used in autonomic computing systems to collect data from different data sources with many different formats. The GLA is a rule-based engine that can translate data from different native log formats into a standard format, known as the Common Base Event format (CBE), through rules written using regular expressions—a common mechanism used traditionally for search functions. In the GLA, rules can be written on a per property basis. Therefore, a rule may describe a mechanism to extract a portion of the input string and populate a field of the Common Base Event that is provided when all the rules for all the properties have been applied to the input string in the native format. A single property may have a number of associated rules, because different strings in the same native log/event format might represent the same information in different ways or in different positions within the complete data string.
The Generic Log Adapter may utilize regular expressions to describe the parsing rules which may allow decomposition and reassembly of proprietary product messages/log files into CBE format. One advantage of using a generic adapter is that the parsing rules can be customized as required by a particular vendor or end-user, and also can be extended to include new message types added to the logs and include application level messages that may manifest themselves in system level logs. For example, while it may be possible to write a parsing component (generic or static) for IBM's WebSphere Application Server (WAS), it may parse only message types in WAS. As such, a message from another application which may appear in the same log file may not be parsed using the same code/rules. By using a generic adapter, the rules can be modified to fit new message types that were not known at design time. The generic adapter may use regular expressions because they are standardized, and may provide powerful constructs to match and extract matched entities from input messages.
In some cases, however, it may be difficult to write rules using regular expressions to extract or assign values to some properties. This may be due to a number of factors. First, it may not be possible to derive the information from the input message. For example, a globally unique identification (e.g., globalinstanceId) often does not exist for message log entries, which may make it impractical to define such an ID statistically per log entry or from different fields in the input log message. Second, the data extracted from the input message may require some manipulation that may not be possible using any of the regular expressions constructs. For example, in Cisco (IOS) log files, the host names may often be provided as aliases. Converting these aliases into actual IP addresses may require some operations that are not within the scope of the generic adapter, because a specific operation may be used for the specific log file. Third, while it may be possible to perform certain operations using regular expressions, it may be preferable to use code. A typical dilemma arises when half of the parsing can be done more effectively with regular expressions and half with regular code. While code may be faster in these cases, it is also static. The issue may become more complex if the code requires some portions of the input message as parameters, which may have to be extracted using regular expressions and/or string operations. Fourth, state information may be required to be maintained between input messages, which may be difficult when using regular expressions or rule based parsing because each of the rules may be executed in isolation. While it may be possible to maintain state information within the execution scope of a rule, it may not be possible to do so across rules involving different regular expressions. Finally, the person writing the rules may not have an intimate knowledge about particular fields. In such cases, he/she may choose to use the GLA's better understanding of the properties to fill those fields. He/she may also aid the Generic Adapter by providing regular expression to extract the message portions that may be of interest to the Generic Adapter for filling the fields, while allowing the adapter itself to perform final transformations before filling the particular fields. By working in such a collaborative fashion, common knowledge available within the adapter can be leveraged with scenario/case specific knowledge provided by rules written by a domain expert/end user.